% THIS IS SIGPROC-SP.TEX - VERSION 3.1
% WORKS WITH V3.2SP OF ACM_PROC_ARTICLE-SP.CLS
% APRIL 2009
%
% It is an example file showing how to use the 'acm_proc_article-sp.cls' V3.2SP
% LaTeX2e document class file for Conference Proceedings submissions.
% ----------------------------------------------------------------------------------------------------------------
% This .tex file (and associated .cls V3.2SP) *DOES NOT* produce:
%       1) The Permission Statement
%       2) The Conference (location) Info information
%       3) The Copyright Line with ACM data
%       4) Page numbering
% ---------------------------------------------------------------------------------------------------------------
% It is an example which *does* use the .bib file (from which the .bbl file
% is produced).
% REMEMBER HOWEVER: After having produced the .bbl file,
% and prior to final submission,
% you need to 'insert'  your .bbl file into your source .tex file so as to provide
% ONE 'self-contained' source file.
%
% Questions regarding SIGS should be sent to
% Adrienne Griscti ---> griscti@acm.org
%
% Questions/suggestions regarding the guidelines, .tex and .cls files, etc. to
% Gerald Murray ---> murray@hq.acm.org
%
% For tracking purposes - this is V3.1SP - APRIL 2009

\documentclass{sig-alternate}

\begin{document}

\title{Annotating Security in the Cloud}

%
% You need the command \numberofauthors to handle the 'placement
% and alignment' of the authors beneath the title.
%
% For aesthetic reasons, we recommend 'three authors at a time'
% i.e. three 'name/affiliation blocks' be placed beneath the title.
%
% NOTE: You are NOT restricted in how many 'rows' of
% "name/affiliations" may appear. We just ask that you restrict
% the number of 'columns' to three.
%
% Because of the available 'opening page real-estate'
% we ask you to refrain from putting more than six authors
% (two rows with three columns) beneath the article title.
% More than six makes the first-page appear very cluttered indeed.
%
% Use the \alignauthor commands to handle the names
% and affiliations for an 'aesthetic maximum' of six authors.
% Add names, affiliations, addresses for
% the seventh etc. author(s) as the argument for the
% \additionalauthors command.
% These 'additional authors' will be output/set for you
% without further effort on your part as the last section in
% the body of your article BEFORE References or any Appendices.

\numberofauthors{2} %  in this sample file, there are a *total*
% of EIGHT authors. SIX appear on the 'first-page' (for formatting
% reasons) and the remaining two appear in the \additionalauthors section.
%
\author{
% You can go ahead and credit any number of authors here,
% e.g. one 'row of three' or two rows (consisting of one row of three
% and a second row of one, two or three).
%
% The command \alignauthor (no curly braces needed) should
% precede each author name, affiliation/snail-mail address and
% e-mail address. Additionally, tag each line of
% affiliation/address with \affaddr, and tag the
% e-mail address with \email.
%
% 1st. author
\alignauthor
John Edstrom\\
       \affaddr{Virginia Tech}\\
       \email{edstromj@vt.edu}
% 2nd. author
\alignauthor
Michael Woods\\
       \affaddr{Virginia Tech}\\
       \email{mjw87@vt.edu}
}
\maketitle
\begin{abstract}
Platform-as-a-Service (PaaS) offerings are fundamentally changing traditionally held beliefs
about software deployment environments. Developers can no longer assume that they control
the entirety of the software stack: the source, the compiler, the run-time environment, etc.
In PaaS, developers write code locally and deploy it ``in the cloud.''
While decoupling ownership of the deployment environment from the developer has benefits
(i.e. - load balancing, storage), it hinders the developer's ability to specify secure data
flow assertions. When developers no longer control the data, they can make no guarantees
to end users about the security of their data.

To address these shortcomings of PaaS, we present \emph{AnnoFlow}, an annotation 
framework for CloudSpace (a PaaS offering) that allows developers to define 
application-specific data flow assertions. We demonstrate how developers
can protect sensitive data in the cloud. In addition, we introduce an auditing framework 
that enables developers to retrieve relevant performance metrics from their cloud-based 
applications. Finally, we evaluate the performance overhead associated with \emph{AnnoFlow}.
\end{abstract}

% A category with the (minimum) three required fields
%\category{H.4}{Information Systems Applications}{Miscellaneous}
%A category including the fourth, optional field follows...
%\category{D.2.8}{Software Engineering}{Metrics}[complexity measures, performance measures]

%\terms{Theory}

%\keywords{ACM proceedings, \LaTeX, text tagging} % NOT required for Proceedings

\input{text/introduction}

\section{Implementation}

To address the limitations we have discovered in the contracts between platform as a service cloud clients, we have developed an infrastructure
for embedding policies and boundaries in a cloud environment.  Our policy and filter architecture closely
mimics the RESIN infrastructure created at MIT.  However, in contrast to the RESIN framework, our framework
focuses on creating barriers within the cloud environment and logging the results of policy evaluations.

\subsection{Policies}

Our policy framework emphasizes applying policies to both classes and objects.  Policies associated
with JAVA classes and JAVA objects are defined using JAVA annotations.  The policy classes themselves provide 
functionality to asses the policy in an executing context, asses the need to audit the policy at a point of 
code executions, and generate policies for instances of objects with annotated class types.

To associate policies to classes and objects, AnnoFlow provides application developers with a PolicyManager
class.  This class provides static methods for associating policies to classes and objects.  Because classes are never unloaded from the system class loader,
AnnoFlow associates classes permanently to a policy using a Hash Map.  Objects however, have a limited lifetime in JAVA.
When instance objects are associated with a policy in the policy manager, a weak identify hash map is used.  This
allows objects to be associated with policies in the hash map for their lifetime in the application.  Then,
when the object is marked for garbage collection, the association to a policy in the policy manager will not
force the JAVA garbage collector to keep the object in memory.

To define the association of policies to objects and classes, JAVA annotations are used at the top of the class definition.
The policy annotations consist of a generic policy annotation and an associated policy type.  These policy
types all inherit from a common interface.  In addition to defining methods for general policy functionality,
the policy interface defines a method for generating the code that will associate the class to the policy.  The code
snippet is then used by the AnnoFlow framework to inject into the application.

By default AnnoFlow uses the Javassist byte code engineering framework to inject policy associations directly
into developer compiled code.  However, as we will discuss in later sections, our framework is flexible enough
to use other frameworks such as JBoss AOP and AspectJ.  Javassist was chosen as the default byte code engineering
solution because of the high level of control it provides to the developer.  This level of control is important
because of the prototype nature of the AnnoFlow project.  Javassist was also used for its easy integration
into the CloudSpace platform.

Using Javassist, the generated policy code generally calls a static class function and registers itself with
the Policy manager.  The policy code returned is any syntactically correct set of java expressions.
The policy code contains all setup needed or pass any required parameters to the function that will
register the policy with the class.

When associating classes with policies, all associations are performed when the class is loaded by the application.
AnnoFlow injects the policy binding directly into the static initialization block for the class.
However, when an instance of an object is associated with a policy, the association is created a the time of object
instantiation.

This object to policy association is performed by calling the generatePolicy method defined in the Policy interface.
This method uses various tools to inspect the current thread stack to understand the context surrounding the object's
instantiation.  After performing the logic to investigate the origin of the current object, the generateOrigin method
returns the type of policy that should be associated with the new object.  For example, in a set of policies tracking
the creation of secure objects, the generateOrigin method might investigate the stack trace and attempt to determine
what class is creating the object.  If that class is a secure class, then the object created would be considered secure;
however, if the calling class is considered insecure, then the subsequent object should also be considered insecure.

Policies also provide a method for auditing the policy as it passes through certain filters.  This audit method contains
the logic to form an audit entry in the AnnoFlow provided Logger static class.  The Logger static class gathers the minimum
amount of information from the policy to record the flow of an object through filter boundaries.  This information is then
made available for later retrieval and analysis.  The logger will be discussed later in detail.

Finally, policy objects are able to asses their own flow according to an executing context.  This means that an application
may know the type of execution that is about to occur without knowing specific policies it should not execute using.  The asses
method in policy objects allow applications to pass them a generic set of operating context that the policy can then decide if
it should be operating in.  If it shouldn't, the policy asses method is expected to throw an exception.

\subsection{Filters}

After linking policy information to classes and instances of objects, AnnoFlow provides developers with a mechanism to analyze
an object's policy at specific points in application execution.  These borders are annotated and automatically injected by AnnoFlow.

To annotate code borders in AnnoFlow, the user adds a Filter annotation on methods they intend to use as a border.  The annotation
is standard; however, the annotation is passed a class that implements the FilterPoint interface as a parameter.  For each annotated method, AnnoFlow injects code into
the existing method using method calls on the annotated filter.  This injection occurs at class load time and adds compiled byte code
directly into the method call.

By default AnnoFlow restricts the injection of filter code as a call before the method is executed or after the method is executed.  This is an attempt to simplify
annotating methods and to define a clear strategy for including filters.  However, the AnnoFlow framework could be used with different
byte code engineering frameworks.  In this case, the filter code could be injected else where in the method body.

While annotating methods is acceptable when the developer has access to the method's source code, annotating library code becomes
more difficult.  In other situations, developers may need to create a final class or method that cannot be modified.  In these situations,
AnnoFlow provides a second mechanism for adding filter code to methods.  Instead of modifying a method body, AnnoFlow also allows developers
to specify code to surround a method call.

To specify the code to surround a method call, AnnoFlow provides a custom configuration system for Javassist.  The configuration system allows
developers to specify the class, method, replacement code, and replacement algorithm to use.  The replaced code works exactly the same as the
filter code method in the filter interface.

\subsection{Logger Framework}

One of the biggest short comings of cloud computing is the inability of a developer to see cloud execution after
uploading the application to the cloud.  In many cases, the developer must give a large amount of trust to the cloud operator to live up to
the service contracts that have been promised.  Because the AnnoFlow framework is focused on cloud deployment, AnnoFlow aims to create a high 
level of transparency in it's operations.

To provide this transparency, AnnoFlow provides a logging framework to log filter and policy messages for instant retrieval.  When policy or
filter logic is evaluated, they can choose to log things to a static Logger class.  This logger organizes the policy output for the developer.
The logger tracks things such as the method triggering a filter evaluation, the filter evaluated, the policy involved, the time stamp, and the
return state of the policy evaluation.

As the application runs and logs are collected, they are made available to the cloud framework to display to the user.  In our prototype of
AnnoFlow, we provided an implementation of a logging interface in CloudSpace.  In our prototype, the logger will store information in an unbounded fashion.  However,
as a more stable improvement, AnnoFlow could allow it's logger to be configured to store logging information for a reduced amount of time.

The logging interface has two panels.  On the left, the web application displays all of the evaluated filters in the application.  These 
filters are clickable and reveal information about each of the filter executions.  Each execution instance shows data about state of 
the application when the filter was evaluated.  Using a refresh button, the logging interface displays real time information 
about the current stored logs.  

\subsection{Default Configurations}

After the methods are annotated, developers can then make boundaries around the data within the application code.  However, the logic
is generally very customized to the cloud environment that the application is executing in.  To provide some examples and very simple
implementations, AnnoFlow provides a few standard boundary filters to developers.

The first filter set provided is a secure and insecure filter and policy set.  This default policy and filter set allows developers to mark
certain classes and fields as secure.  They are then able to annotate certain classes and fields as insecure.  The developer can then mark
certain methods as boundaries for secure and insecure objects.

When the the application executes, the annotated method boundaries will be respected by the call flow of the application.  By default, secured
classes will not allow insecure or non annotated classes to call secured methods within the class.  In addition, the default boundary policies
will audit all security evaluations and log them to the centralized AnnoFlow logger framework.  If the method call violates the security
parameters, then an exception will be thrown.

Also included is a simple file system locality filter.  This filter is configured through the Javassist configuration file method to check the
locality of all file bound input and output streams used in the application.  At the point of stream creation, AnnoFlow checks the underlying,
file path for a specific directory that represents a remote directory.  At the point of FileReader creation, AnnoFlow will automatically
dump the stack trace and analyze it for a class in the stack that has been annotated with a local policy annotation.  If this annotation is found,
AnnoFlow will throw an exception to halt execution.

\subsection{Context Tracker}

As the AnnoFlow framework was developed, we discovered that many of the policies and filters required an understanding of their current executing
context.  However, our initial implementations used an inefficient system of dumping a thread's stack trace and iterating through the elements contained.
This approach was very slow and could be improved with our contextual information.

Instead of requiring developers to use stack trace dumps throughout their code, AnnoFlow provides a Context Tracker utility class to access context flow
details within filter classes.  The context tracker class provides filter methods with details of the class containing the method that is being filtered and
the name of the class that is calling the filtered method.  Basically, the context tracker class provides the first two levels of the thread's stack trace.

To set the fields within the context tracker, AnnoFlow adds calls into the context tracker before any method call where the method definition is annotated
and directly before any filter code is executed.  After the filter has executed, the context tracker is cleared to prevent any spill over into another filter
call.

\input{text/examples}

\input{text/performance}

\section{AnnoFlow in the Cloud}

AnnoFlow does not add much innovation in the security space.  While it is capable of preventing XSS injection attacks and SQL injection attacks, AnnoFlow
shines when creating barriers for platform as a service service level agreements.  In particular, AnnoFlow is able to prevent data from flowing to untrusted
portions of the cloud.

During our research, we integrated AnnoFlow into the CloudSpace platform to better understand the performance losses and the general use cases for AnnoFlow.
We quickly realized that the amount of annotations required to prevent SQL injection or XSS attacks would be unmanageable in a large scale system.  However,
using annotations to separate the client code from the platform code was a much more viable option.

Using AnnoFlow to create barriers in the cloud only requires the client developer to annotate their most basic objects with a single annotation on the class
definition.  Then when platform developers create the API's that client developers will use to access the platform's services, they annotate the methods with
filters to check the policies being passed in.  This way, basic objects containing secured data can be restricted to use within client code.

When we created a demo facebook application on CloudSpace, we saw this advantage first hand.  In this case, we used two annotations to create a barrier between the client
and the platform.  The first annotation was placed on the User class.  This annotation specified that the User class was a secure policy and that when user classes
were created, the instantiated User objects should also be secure.  Then a filter annotation was added to the toString method within the User class.  This filter
prevented the getPassword method from being called by a class without the proper secure policy annotation.

Once the annotations were setup, we used the web UI generation service provided by CloudSpace to generate a User interface that referenced a user object and inadvertently
called the toString.  In this case, the toString method was executed by a reflective recursive call within the CloudSpace framework.  Because this reflective call was not performed
by a secure class, AnnoFlow threw an exception to prevent further execution.

This type of barrier support allows AnnoFlow to ``protect'' the client code from changes in the platform surrounding it.  In platform as a service cloud computing, it
is common that the platform can shift and evolve around client code adding new features and modifying features around the client.

\input{text/relatedwork}

\input{text/conclusion}

%
% The following two commands are all you need in the
% initial runs of your .tex file to
% produce the bibliography for the citations in your paper.
\bibliographystyle{abbrv}
\bibliography{bibliography}  % sigproc.bib is the name of the Bibliography in this case
% You must have a proper ".bib" file
%  and remember to run:
% latex bibtex latex latex
% to resolve all references
%
% ACM needs 'a single self-contained file'!
%
%APPENDICES are optional
%\balancecolumns
\balancecolumns
\end{document}
